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Abstract of 


SHIPBOARD NON-TACTICAL AUTOMATED DATA PROCESSING 

(SNAP) 

RESYSTEMIZATION: AN ALTERNATE APPROACH 

The next generation of Shipboard Non-tactical Automated Data 
Processing (SNAP) systems is now being designed. A historical 
review of the development of the original generation of 
shipboard non-tactical computer systems (SUADPS) shows an 
evolutionary rather than a revolutionary approach to shipboard 
logistics system development. 

Current non-tactical information system (IS) development 
practices are resulting in multiple systems that perform the 
same function. The Intermediate Maintenance Management System 
(IMMS), Maintenance Resource Management System (MRMS) and Naval 
Aviation Logistics Command Management Information System 
(NALCOMIS) have all been developed for intermediate level 
maintenance management. 

Development of the next generation shipboard non-tactical 
logistics information system must stress a standardized 
integrated maintenance approach. Control of non-tactical 
information system development should be exercised by the Navy's 
Deputy Chief of Naval Operations for Logistics to ensure 
adherence to logistic support policy and standard system 
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development. ^ 









PREFACE 


This paper is designed to show the historical development 
of shipboard non-tactical automated data processing systems. 

In presenting a historical overview of automated logistics 
system development, it is hoped that the Navy may learn from 
mistakes made in past shipboard computer development efforts. 

Primary sources for this paper come from 25 years of 
professional articles published in the Navy Supply Corps 
Newsletter. Conversations with personnel in the SNAP program 
office, OP-04, and NAVMASSO provided direction and assistance 
in understanding the past and current shipboard automated 
logistics development efforts. 

The bibliography is not limited to shipboard non-tactical 
automated data processing systems, but covers the Navy's stock 
point (UADPS) and inventory control point (UICP) automated 
systems as well. Resource documentation of U.S. Air Force and 
U.S. Army automated logistics systems are included to provide 
starting reference points for any follow-on projects. 

The alternate system proposed is not fully developed in 
the paper. The intent of the alternate proposal is to 
highlight the need to develop a configuration based integrated 
maintenance system. Additionally a maintenance management 
approach that spans organizational, intermediate and depot 
level maintenance systems is advanced. 
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SHIPBOARD NONTACTICAL AUTOMATED DATA PROCESSING 

(SNAP) 

RESYSTEMIZATION: AN ALTERNATE APPROACH 
CHAPTER I 
INTRODUCTION 

The Problem. The current central processing unit (CPU) or 
main computer hardware for the Shipboard Nontactical Automated 
Data Processing (SNAP) II system is nearing the end of 
manufacturer's support. Several peripheral components for the 
SNAP I system are also reaching the end of their service lives. 
The Space and Naval Warfare Systems Command, and the Naval 
Supply Systems Command have jointly entered into concurrent 
projects to replace and upgrade selected hardware and software 
systems now running under the SNAP I and SNAP II systems. 

The Space and Naval Warfare Systems Command's effort is 
directed to the resolicitation of hardware under the title of 
"SNAP III". The initial software design for incorporation with 
the SNAP III architecture is the Shipboard Uniform Automated 
Data Processing System (SUADPS) resystemization project under 
the sponsorship of Naval Supply Systems Command. 

The redesign of the Supply inventory and financial 
processing software under the SUADPS resolication independent of 
a total shipboard nontactical automated data processing system 
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to include organizational and intermediate level maintenance 
capabilities repeats the original development errors and the 
inherent problems that have plagued the current generations of 
SNAP I and SNAP II systems. 
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CHAPTER II 


HISTORY OF SHIPBOARD HON-TACTICAL AUTOMATED DATA PROCESSING 

Development of automated supply and maintenance systems for 
Naval ships has occurred in five distinct phases. The first 
three phases closely followed the development of similar 
automated supply systems for Naval supply activities ashore, but 
the development and implementation of these first three phases 
of shipboard systems normally followed the shore system 
development by three to five years. 

The first phase of shipboard supply automation began with 
the introduction of Electronic Accounting Machines (EAM) punch 
card systems in 1958. The first systems were IBM 402 equipment 
installed on AKS type ships. 1 Follow-on EAM punch card systems 
were developed and installed on afloat units using IBM 402/407 
and UNIVAC 1004 equipments. 

The development and fielding, in 1963, of the Uniform 
Automated Data Processing System (UADPS) for ashore supply 
management at the Navy's stock points led to the initial 
development of the shipboard logistical computer system, based 
on the UNIVAC U1500 analog computer. 

The second phase of shipboard non-tactical automated 
systems began with first installation of the U1500 computer 
system in June 1966 onboard the USS AMPHION (AR 14). 2 This 
first U1500 system was designated as the Interim Tender System. 
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The first aircraft carrier U1500 installation was onboard USS 
ESSEX, also in 1966. The carrier system was designated as the 
Interim Carrier System. These first installations and the 
implementations that followed, were emulations of existing EAM 
systems that provided an upgrade from existing system 
capabilities in that the Master Stock Record was created and 
updated on magnetic tape. All other functions performed on the 
interim systems were punch card based. 3 The U1500 computer 
system designated as the AN/UYK-5(V) shipboard computer 
consisted of a Central Processing Unit (CPU) with a static 
Random Access Memory (RAM) of 12 Kilobytes, later upgraded to 16 
kilobytes of memory, a combination card reader/puncher, a high 
speed printer, and magnetic tape drives. 

The third phase in shipboard automation was the fielding of 
the fully tape oriented Uniform Tender System onboard USS 
SHENANDOAH and the Uniform Carrier System onboard USS 
INDEPENDENCE in 1968. 

The Uniform Tender System and the Uniform Carrier System 
were developed to create a computerized system that would 
improve afloat supply inventory control and financial management 
and be more responsive to user requirements. The major 
objectives for the Uniform Tender and Uniform Carrier Systems 
were: 


-To provide information on stocked material to 
shipboard management in more accessible and useable 
form than is currently available with the existing 
manual, EAM and Interim U-1500 systems. 
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-To provide the capability for daily updating of 
records, applying improved reorder decision rules and 
generating comprehensive and meaningful data for 
management review. 

- To improve supply responsiveness to user 
demands at the point of issue. 

-To provide for automatic validating and 
processing of supply aids. 

-To provide for the collection and maintenance of 
more definitive data for use in automatically 
adjusting stock levels. 

-To improve report and record accuracy and reduce 
clerical errors by mechanically validating all input 
data. 

-To provide the capability for pertinent exchange 
of data in automated format between forces afloat and 
the shore establishment. 

-To provide for the maximum practical file 
automation with exception transactions that must be 
manually reviewed. 

-To provide for automatic application of change 
notice action and maintenance of stock number cross 
reference changes tailored to the ship's inventory. 

-To provide for physical inventory procedures 
with maximum flexibility in the selecting and 
scheduling of physical inventory and location 
validation. 

-To provide for automatic preparation of required 
reports for financial summaries, order and shipping 
time analysis, supply effectiveness, and other 
management reports. 

-To provide for automatic preparation of periodic 
reports to administer departmental budgets and OPTAR 
funds. 

-To provide Maintenance Collection Data for 
processing 3-M reports. 4 


The Uniform Tender System was developed for implementation 
on Tenders and Repair Ships (AD/AR/AS classes). This system as 
well as the Carrier Uniform System, the Interim U1500 EAM 
emulation system and the ashore Uniform Automated Data 
Processing System (UADPS) was developed by the Navy Bureau of 
Supplies and Accounts/Navy Supply Systems Command's Fleet 
Material Support Office (FMSO). The design and implementation 
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of the shipboard U1500 based automated data systems was 
performed by the Fleet Material Support Office's Fleet 
Assistance Group, Atlantic (FAGLANT). 

The centralization of design and implementation of 
automated data systems vas a development of lessons learned from 
the second generation of shore based automated supply systems. 
These systems were the first computer based supply systems, that 
implemented the same basic operating systems and procedures that 
had been running on the EAM systems. These first generation 
'true' computer systems were developed on a decentralized basis 
by each activity. As a result of each activity designing and 
implementing their own system control of was lost over uniform 
design. 5 

The centralized design of automated data systems at what is 
designated as a Central Design Agency (CDA), gives the Navy a 
level of control of system design and development. The Navy 
Supply Systems Command recognized the need for centralized 
design in the development of the Uniform Automated Data 
Processing System (UADPS) and the afloat Uniform Automated Data 
Processing Systems. As described by Rear Admiral B.H. Bieri, 
SC, USN, then Chief of the Supply Corps in 1968: "There are, of 
course, side benefits to this effort. When a centrally designed 
system finally reacts, it is complete and uniformly applied. 
Over-all implementation actually takes less time than 
individually designed systems." 6 


6 






Centralized design and control of the Navy's automated 
logistics computer systems also allows conformance with mandated 
Department of Defense (DOD) logistic Military Standards 
(MILSTANDARD) programs. Figure number 2-1 shows some of the 
mandated DOD MILSTANDARD programs that impact logistic system 
design and implementation. 

The Uniform Tender System and the Uniform Carrier System 
were converted in 1971 to the Shipboard Uniform Automated Data 
Processing System (SUADPS). This system was a refinement of the 
preceding Tender and Carrier system and was still based on the 
AN/UYK-5(V) UNIVAC U1500 tape-based computer system. The 
Shipboard Uniform Automated Data Processing System (SUADPS), was 
still divided into two distinct systems, SUADPS-207 for all '207 
class' accounting ships such as tenders and repair ships, and 
SUADPS-EU for 'end use ships'^ carriers. The first ships to 
receive these systems were the USS SIMON LAKE, SUADPS-207 and 
the USS WASP, SUADPS-EU. 

While the Uniform Tender System, the Uniform Carrier System 
and the Shipboard Uniform Automated Data Processing System End 
Use (SUADPS-EU) and Shipboard Uniform Automated Data Processing 
207 Class (SUADPS-207) were tape-based systems, they still 
relied heavily on punch card technology. Punch cards were the 
primary input interface that these systems relied on. 

The SUADPS systems provided the following application 
programs: inventory control, stock management, financial, 
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management aids, 3-M maintenance data collection (MDC) and 
utility programs. 

"SUADPS has been designed as a modular system and is based 
on the concept that each component of a program is self- 
contained and performs only a specified function. A master 
executive component regulates the actions of all other 
components." 7 Figure 2-2 shows the 1975 existing and proposed 
population of SUADPS. 

The fourth phase of the shipboard non-tactical automated 
data processing systems consisted of the hardware upgrade and 
conversion of the AN/UYK-5(V) UNIVAC U1500 computer to the 
Honeywell DPS-6 computer system. This hardware conversion 
allowed the conversion of the Shipboard Uniform Automated Data 
Processing System (SUADPS) from a tape oriented, batch 
processing system to an on-line disk oriented system. The major 
benefit of this conversion was that it allowed on-line access to 
data in SUADPS to users outside the Automated Data Processing 
Center onboard ship. 

As a side issue, during the development of the SNAP I and 
later SNAP II systems, the Fleet Material Support Center was 
developing as the Trident Logistics Data System for support of 
the new Trident Class of submarines and their refit bases. This 
effort was sponsored by Commander Naval Sea Systems Command code 
PMS-396. The Trident Logistic Data System was designed from the 
beginning as a unique system for the total logistics support of 
the Trident class of submarines and their refit facilities. 
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The Trident LOS was designed as a maintenance based system 
to aid in patrol-refit cycle maintenance and support and to 
provide a maintenance based configuration management system for 
the weapon system. The philosophy of the Trident LOS design and 
implementation will be discussed in Chapter III. 

SNAP I consisted of three shipboard configurations (Figure 
2-3) and one configuration for naval air stations for aviation 
maintenance. Descriptions of the three shipboard configurations 
are as follows: 

Hardware for Configuration A, now being installed 
under Phase II, consists of 3 inter-connected sub¬ 
systems: a processor, a mass-storage sub-system, and 
a local peripheral sub-system. Configuration A does 
not add new software but supports current batch 
operations though emulation of existing software. It 
adds CRTs to replace card punch machines. 

Configuration B will have Configuration A 
components plus at least two remote peripheral sub¬ 
systems with additional terminals and character 
printers. New software development for Configuration 
B is underway at NAVKASSO, the Central Design Activity 
for all SNAP software. This new software will include 
the following: 

Shipboard Uniform Automated Data Processing 
System Real-Time (SUADPS-RT). A single, comprehensive 
supply and financial accounting system for all large 
ships. 

Intermediate Maintenance Management System-Real 
Time IMMS-RT). A means of collecting maintenance data 
and providing management information at Navy 
intermediate maintenance sites. 

Pay and Personnel Administrative Support System- 
Source Data System Afloat (PASS-SDSA). A means of 
handling all personnel and military pay information 
for forces afloat. 

Organizational Maintenance Management System-Real 
Time (OMMS-RT). A data collection and maintenance 
management information system geared to organizational 
level maintenance, which is performed by a member of 
the ship's own crew. 

Configuration C is designed for afloat aviation 
units that require a large ADP capacity to support 
SUADPS-RT, IMMS-RT and the Naval Aviation Support 
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Management Information System (NALCOMIS). 

Configuration C will have an additional processor, 

mass storage, and remote peripheral sub-systems.* 

Figure 2-4 provides the current status of software 
implementation of the various existing versions of the SUADPS 
system. Current plans call for all existing SNAP I/SUADPS 
systems to be upgraded to SUADPS release 3.0 which will allow 
terminal users to access SUADPS data on a real-time basis. 

Maintenance system development for the Shipboard Non- 
tactical Automated Data Processing systems are covered in 
chapter three. 

The SUADPS and SNAP I systems were developed for and 
installed on the Navy's largest ships. With the development of 
smaller, more powerful mini-computers, space and cost 
requirements, that prohibited the installation of SUADPS on 
smaller combatants, were no longer constraints to installing 
automated logistics systems onboard the smaller ships. 

The development of the Shipboard Non-tactical Automated 
Data Processing (SNAP) Phase II logistics system was initiated 
in the early 1970s. David Taylor Naval Ship Research and 
Development Center, conducted as study aboard two ships in 1974 
and 1975. The study, known as DEAS Information Networks Study 
Phases I and II completed in 1975 and 1978 respectively, formed 
the informational database for the shipboard requirements and 
ship to shore data flow required to implement a total shipboard 
logistics system. 
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While the SNAP II system studies and hardvare/softvare 
prototyping were being conducted, several fleet units acquired 
microcomputers and developed their own shipboard non-tactical 
automated data programs. Most notable of these systems was the 
system developed on USS KING (DDG 41), by Lieutenant Harry 
McDavid, SC,USN. The system titled "Micro-RING" was built 
around a commercially available Televideo 806 microcomputer 
system using Control Program/Microcomputer (CP/M) programming 
language and Aston-Tate "dBase II" database application 
software. The system was assembled for under $10,000 
(Commanding Officer approval authority in 1982-83) . The Micro- 
KING system provided automation of supply financial reports, 
requisition status reports, requisition processing, and 
disbursing functions. 9 

The Navy's answer to the needs of the smaller ship's SNAP 
II from its inception had a broader goal than the 
supply/financial and limited maintenance support provided by the 
Standard Uniform Shipboard Automated Data Processing System 
(SUADPS) and limited applications developed by shipboard 
personnel using microcomputers. SNAP II's initial design 
envisioned total integrated shipboard non-tactical automation of 
all logistic and administrative functions. Functional areas to 
be initially included in the SNAP II system were; 
administration personnel records, medical and dental records, 
disbursing, food service management records, retail operations 
management, implementation of the Navy's Maintenance and 
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Material Management (3-M) system (Planned Maintenance System and 
Material Data Collection) and Consolidated Shipboard APL List 
(COSAL) as on-line databases. 10 Figure 2-5 provides a list of 
SNAP II software application programs. 

The SNAP II system was designed to meet the following 
requirements: 


Be operable and maintainable afloat without 
specialized data processing personnel 

Be capable of sufficient growth to satisfy 
foreseeable non-tactical information processing 
requirements aboard ship. 

Be software and data compatible with the AN/UYK 
5(V) replacement system (SNAP I). 

Be capable of off-line data exchange with 
interfacing automatic data processing and 
communications systems. 

Have a projected serviceable life in the 
shipboard environment sufficient to achieve economic 
payback thresholds. 

Have sufficient security protection capability to 
prevent unauthorized access to ship's data. 11 

SNAP II hardware was acquired through a minority small- 

business set aside contract under the Small Business 

Administration Section 8(a) program. The contract was awarded 

in November 1981 and the winning contractor was Systems 

Management America (SMA) of Norfolk, Virginia. The Snap II 

system hardware designated the AN/UYK-62 (V) was designed to be 

fielded in four configurations: small, small (submarine), 

medium, and large. The primary differences between the 

configurations being the number of peripherals and disk storage 

capacity. 12 The primary SNAP II hardware elements are: a Harris 

super-microcomputer H-300 for the main processor with a fixed 

hard disk drive system, a high speed line printer and remote 
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SNAP tl SOFTWARE 
application PROGRAMS 


Organizational Maintenance 
Management Subsystem (OMMS) 

• Current Ship's Maintenance Project 

• Work Package Processing 

• Approval Cycle Processing 

• Automatic 4790. Ck Form Generation 

• On-line Trouble Log 

• Preventive Maintenance Subsystem (PMS) 

• Measure 

• Automated Technical Document File 

• Navy Technical information Presentation 
stem (NT1PS) 

• Supply/Financial Management Subsystem 
(SFM) 

• Automated COSAL 

• On-line Stock Record File. Material 
Outstanding File. Status File. Cro«s Reference 
File 

•Inventory Management. Including 
Reorder Review 

• Financial Module (OPTAR. Department 
Budget) 

• NAVSCP 1250 and Requisition Genera¬ 
tion 

• AVCAL (Ilelo DETS) 

• Food Service and Retail Operations 
Modules 

• Disbursing 

• Mobile Logistics Support Force (MLSF) 
Administrative Data Management Subsystem 
(ADM) 

• Personnel Administration Module 

• Watch. Quarter and Station Rill 

• Berthing Bill 

• Division Officer's Notel>ook 

• Career Counselor Module 

• Medical Module 

• Word Processing (Ml’SF.) 

• Mailing Lists 

• Social Roster 

• Recall Bill 

• PASS/SDSA 


FIGURE 2-5 
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"dumb" terminals. The first prototype installation of the SNAP 
II system was on USS SIDES (FPG 14) in October 1982. 13 

By May 1984, 24 Surface Force Atlantic (SURFLANT) ships had 
SNAP II installed with five additional SURFLANT ships scheduled 
to receive the SNAP II system in Fiscal Year 1984. u 

The initial system design for the SNAP II system proved to 
be overly ambitious. The disbursing, retail operations 
management and food service management modules were removed from 
the SNAP II minicomputer system and developed on stand-alone 
microcomputers. Among other problems, the access time for data 
retrieval proved to be excessive and acted as a deterrent for 
initial users of the SNAP II system. While the Harris H300 
minicomputer provided sufficient processing power to handle the 
installed software applications, the disk access controller 
proved to be the limiting factor in system utilization. 

A sixth phase of shipboard non-tactical automated data 
processing is currently under development. SNAP III consisting 
of phased hardware replacement for the SNAP I and SNAP II 
systems is under development by Commander, Naval Space and 
Warfare Command (SPAWAR) code PMW-164, the Shipboard Non- 
tactical Automated Data Processing systems management office. 
A further development in this sixth phase of shipboard automated 
logistics is the Naval Supply Systems Command's (NAVSUP) 
Shipboard Uniform Automated Data Processing System (SUADPS) 
resystemization project under NAVSUP code 048's direction. 
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The hardware replacement effort Is driven by the two 
problems. First, many peripheral equipment for the SNAP I 
system, specifically the line printer, are reaching the end of 
serviceable life. Secondly the Harris H300 minicomputer which 
is the central processing unit of the SNAP II system will no 
longer be supported by the manufacturer after 1992. These 
factors provide an urgency for the SNAP project office to 
provide new hardware to the fleet. 

The SNAP III system is being designed as the technology 
refreshment of the SNAP I, SNAP II, and the paper ship concept. 
The functional goals that SNAP III is being designed to meet 
are: 

1) accommodate information growth as a result of CALS 

2) improve/maintain the level of data integrity 

3) increase accessibility to the system (connectivity) and 
information (flexibility) 

4) enable easier incorporation of technological advances 

5) anticipate and accommodate user information needs 

growth 

6) develop an open architecture, centrally managed data 
base on file servers. 

Figure 2-6 provides a depiction of proposed SNAP III system 
architecture concepts. 

The SUADPS resystemization project is an effort by the 
Naval Supply Systems Command to review current operating 
procedures for inventory and financial manajement with a view to 
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projected manning and responsibility allocation of Supply Corps 
officer and enlisted personnel in the next two decades. This 
review of current operating procedures is a "bottom-up and top- 
down review" of how the Supply Corps inventory and financial 
management operating policies and procedures could and should be 
changed to reflect the realities of reduced budgets and supply 
billets in the 1990s and the twenty-first century. 

In the beginning of the new decade of the 1990s the 
development of a new Standard Shipboard Non-tactical Automated 
Logistics system faces many challenges. Hardware replacement 
and SUADPS resystemization are but two of many issues to be 
managed in the development of a new system. Perhaps the most 
important issue that must be addressed in the development of the 
new "SNAP III" system is the issue of central design and control 
of hardware and application programs for shipboard logistics 
systems. 

An article in the March/April 1988 edition of the Navy 
Supply Corps Newsletter , shows a decentralized system of 
Information Resource Management (IRM) with Navy Type Commanders 
(TYCOM), third echelon commands controlling either Surface, 
Aviation or Submarine forces on either the East of West coasts 
of the United States, having the authority to develop and 
implement shipboard non-tactical automated data systems to 
supplement or enhance the SNAP I/II systems. Examples of these 
TYCOM developed systems are: Commander Submarine Fores Atlantic 
(COMSUBLANT) has developed a micro-computer LOGMARS bar-coding 
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system. Commander, Naval Air Forces Atlantic (COMNAVAIRLANT) has 
several non-tactical Automated data processing 
systems/applications under development. Among the COMNAVAIRLANT 
initiatives are enhancements of the COMSUBLANT LOGMARS bar¬ 
coding system developed as the Integrated Bar-coding System 
(IBS), and research and development efforts with optical storage 
devices. 15 

These development efforts on part of the varying Type 
Commanders if not controlled, may lead "back to the future" in 
non-tactical automated data processing systems, that the Navy 
found itself in the early 1960s where non-standard systems were 
the norm rather than the exception. 
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CHAPTER III 


AUTOMATED SHIPBOARD MAINTENANCE MANAGEMENT SYSTEMS 

Benjamin S. Blanchard, in his book Logistics Engineering 
and Management , defines maintenance as: 

maintenance includes all actions necessary for 
retaining a system or product in, or restoring it to 
a serviceable condition. Maintenance may be 
categorized as corrective or preventive maintenance. 1 

The Navy's current formal maintenance program dates to 1964 
with the publication of Office of Naval Research Report Serial 
T-170, "A Survey of Information Requirements for Navy 
Maintenance and Material Management." 2 This report led to the 
establishment of the Maintenance and Material Management 
Program, commonly referred to as the 3-M program. The 
Maintenance and Material Management Program was divided into two 
parts, the Planned Maintenance System (PMS), and the Maintenance 
Data Collection System (MDC). 

The Planned Maintenance System (PMS) was developed and 
implemented to provide scheduled maintenance to perform 
preventative maintenance on selected equipment to reduce or 
avoid component or total equipment failure during operation. 

The Maintenance Data Collection System (MDC) was designed 
to gather information on maintenance actions and to collect 
maintenance related material consumption. This system was the 
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earliest maintenance system implementation on shipboard non- 
tactical automated data processing systems and was included in 
the Uniform Tender System and Uniform Carrier System operating 
on the AN/UYK-5 (V) UNIVAC U1500 computer system. 

Since the installation of these first KDC maintenance sub¬ 
systems on the Uniform Tender and Uniform Carrier Systems in 
1968, maintenance sub-systems in various forms have been 
included in all successive shipboard non-tactical automated data 
systems. The scope and complexity of the shipboard maintenance 
systems have increased since 1968. 

The Intermediate Maintenance Management System (IMMS), 
development was sponsored by Naval Sea Systems Command code 
CLD, with the Navy Management Systems Support Office 
(NAVMASSO) acting as the Central Design Agency for the 
development of the program. The project was initially 
developed as IMMS II running on the Shipboard Uniform 
Automated Data Processing System (SUADPS) U1500 computer. 

IMMS was developed to provide selected SNAP I shipboard 
intermediate maintenance facilities (AR, AS, and AD) with a 
production and man-hour accounting management package. The 
IMMS-RT program was developed from the beginning as a phased 
development software system designed to interface, initially 
through a tape input, to the SNAP I SUADPS system. Successive 
IMMS enhancements have resulted in a real time interface with 
the SNAP I SUADPS system under IMMS release 3.0. The first 
implementation of IMMS-RT was onboard USS McKEE in 1982. 
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Currently 22 shipboard IMAs are running either IMMS release 
2.0 or release 3.0. All existing IMMS sites are scheduled to 
receive IMMS release 3.0. 

The Maintenance Resource Management System (MRMS), 
developed under the sponsorship of Naval Sea Systems Command 
(NAVSEA) Code PMS-331, with PMS-331 also acting as the Central 
Design agency, was designed to consolidate three existing 
shore based intermediate maintenance management systems. The 
three systems that MRMS replaced are: Area Maintenance 
Management Information System (AMMIS) developed By Naval 
Surface Forces Atlantic (SURFLANT), Waterfront 
Maintenance Management System (WMMS) developed by Naval Surface 
Forces Pacific (SURFPAC), and Submarine Maintenance Management 
Information System (SMMIS). MRMS was designed to run on the 
Honeywell DPS-6, the standard SNAP I shipboard computer 
hardware. Development of this system was begun in 1986, and was 
first implemented at SIMA San Diego in the spring of 1988, The 
first shipboard installation of MRMS was onboard USS DIXON (AS- 
37) in January 1990. Currently all Shore Intermediate 
Maintenance Activities (SIMA) with the exception of the Nuclear 
Submarine Support Facility (NSSF) New London, run MRMS. Future 
implementations of MRMS are planned in the first and second 
quarters of FY 1990. 

The Organizational Maintenance Management System (OMMS) was 
developed by the Navy Management Systems Support Office 
(NAVMASSO) under the sponsorship of Naval Sea Systems Command 
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code OLD in 1981. The Organizational Maintenance Management 
Systems (OMMS) originally developed under the title Logistics 
Support Center (LSC) was first implemented onboard USS RANGER. 
OMMS is designed to give SNAP I ships an automated 
organizational level maintenance planning, scheduling and data 
collection system. Currently 20 SNAP I ships have OMMS 
installed. The system, originally fielded as a stand alone 
system running on the SNAP I hardware, is being integrated with 
the SNAP I Intermediated Maintenance Management System (IMMS) 
through an Afloat System Interface, (ASI). The Afloat System 
Interface, is an electronic data transfer capability designed to 
allow the Organizational and Intermediate level maintenance 
management systems to share data. 

A further development in the Organizational level 
maintenance systems is the development of Micro-OMMS (MOMMS). 
This system, also developed by NAVMASSO, is designed to give 
non-SNAP ships such as tugboats and Landing Craft, Utility 
(LCUs) an organizational level maintenance management system 
based on a mini-computer (Personal Computer). 

The SNAP II system, designed and developed by NAVMASSO, 
uses what is referred to as the Integrated Logistics Management 
system (ILM) to aid in maintenance and configuration management. 
The SNAP II system provides a modular, integrated database 
linking configuration files, maintenance files and supply parts 
database. 
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The SNAP II ILM allows for maintenance data collection 
using electronic (on-screen) maintenance action forms (OPNAV 
Form 4790/2K) and configuration change reporting (OPNAV Form 
4790/CK). The 1W also builds the ships Consolidated Shipboard 
Maintenance Program (CSMP) file which details which maintenance 
actions have been deferred due to lack; of material or shipboard 
capabilities. 

Two additional shipboard maintenance systems have been 
developed and fielded, the Naval Aviation Logistics Command 
Management Information System (NALCOMIS) and the Trident 
Logistic Data System (LDS). Both systems were designed to be 
used in the afloat and ashore maintenance environments. 

The naval air maintenance system was established by 
OPNAVINST 4790.2, the Naval Aviation Maintenance Program (NAMP). 
The shipboard and air station automation program designed to 
implement NAMP is the NALCOMIS program. NALCOMIS, was developed 
by the Fleet Material Support Office under the functional 
sponsorship of Commander, Naval Air Systems Command code PMA- 
270, the NALCOMIS project management office. The project was 
initiated in January 1977. 3 NALCOMIS provides an integrated 
database for aviation Organizational maintenance Activities, 
Intermediate Maintenance Activities and Supply Support Centers 
aboard carriers and Naval and Marine Corps Air Stations. 

The objectives of the NALCOMIS program are, "...to increase 
aircraft material readiness by improving repairable turn-around 
time and to provide improved visibility of assets." 4 The system 
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was designed to operate on the SNAP I afloat hardware and was 
first fielded at Marine Air Group 14, Marine Corps Air Station 
(MCAS) Cherry Point, North Carolina in 1983. 5 All carrier 
aviation intermediate maintenance departments have the NALCOMIS 
program installed and operating on the SNAP I systems. 

The last shipboard maintenance system to be discussed, is 
perhaps the most comprehensive integrated logistics system 
currently fielded by the Navy, the Trident Logistics Data System 
(LDS). The Trident LDS is not a single program but an 
interactive group of seven sub-program modules that covers not 
only organizational, intermediate and depot level maintenance, 
but include supply support, configuration management and 
overhaul and refit support for the Trident weapon system. 
Figures 3-1 and 3-2 provide diagrams of the integrated Trident 
LDS system network. 

The Trident Logistics Data System was initiated in November 
1971 under Naval Sea Systems Command (NAVSEA) code PMS-396, 
Project Office for the Undersea Long Range Missile System 
(ULMS). 6 The Central Design Agency responsible for design and 
development of the Trident LDS is the Fleet Material Support 
Office. 

The Trident LDS was designed from the beginning as a 
maintenance based system. The design philosophy of the system 
was to support the integration of shipboard maintenance and 
supply support requirements into the broader planning and upkeep 
programs required to support the Trident's patrol cycle. The 
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system was designed to made use of existing automated systems 
such as the Uniform Automated Data Processing System (UADPS) for 
Supply Stock Point support, by developing front end interfaces 
for the Trident LDS, which allowed the Trident LDS to operate 
and exchange data with those systems. 

The Trident Refit Planned Maintenance Management 
System/Refit Maintenance Management System (TRF/MMS) was 
designed to automate the maintenance support operations at the 
Trident Refit Facilities. Taking data compiled from the onboard 
logistics data system and planned refit maintenance data 
provided by the Refit Facility, the TRF/MMS module provides the 
identification of logistic resource requirements for a refit 
period. It also provides data collection that provides 
maintenance management reports, including data required to 
support the Maintenance and Material Management (3-M) system 
Maintenance Data Collection System (MDC). 

The seven maintenance systems described above; IMMS, MRMS, 
OMMS, MOMMS, SNAP II IU!, NALCOMIS and Trident LDS, compose the 
universe of current Hardware System Command (HSC) sponsored 
automated shipboard maintenance systems. As can be expected 
with seven separate maintenance systems, redundance does exist. 
The IMMS and MRMS programs in particular are redundant efforts, 
started as separate systems for intermediate maintenance 
management and were sponsored by different program management 
offices within the Naval Sea Systems Command. Just how much 
redundancy exists among the seven maintenance systems is open to 
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speculation. Chapter V describing an alternate approach for the 
SNAP III program will discuss a maintenance design philosophy 
which could result in the reduction of duplication of 
maintenance systems. 
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Chapter IV 

LOGISTIC AND MAINTENANCE ORGANIZATION RELATIONSHIPS 


The numerous organizations involved in the non-tactical 
logistics information systems development are systematic of a 
larger problem facing the Navy today: control of information 
systems development. The Navy's policy of allowing the 
Headquarters Systems Commands exercise independent logistics 
(ILS) management allows the duplicate development of 
Information Systems, especially non-tactical information 
systems. This chapter will review the functional and resource 
relationships of the Shipboard Non-tactical Automated Data 
Processing program office. The review of this one project 
will show the multiple organizations that are commonly 
involved in development of non-tactical information systems in 
the Navy. 

While the SNAP Program Office is directly responsible for 
the hardware procurement for the Shipboard Non-tactical 
Automated Data Processing systems, it also has oversight 
responsibilities of the software systems developed to operate 
on that system. The SNAP Program Office, however, does not 
directly control the requirements or the design of the 
software modules developed to run in the SNAP hardware. 

Various functional managers serve as "executive agents" to 
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determine the functional requirements for the sub-systems that 
make up the SNAP software system. Figure 4-1 shows a matrix 
of information system sponsors and functional area managers 
for the various functions running on the SNAP hardware. 

The Naval Supply Systems Command serves as the functional 
manager for the inventory control and shipboard financial 
management software modules for the SNAP I and SNAP II 
systems. OP-43 is the functional requirements manager for the 
shipboard organizational and intermediate maintenance software 
module for the SNAP systems. 

Aviation maintenance management systems and their 
interface with the SNAP I system is provided by Naval Air 
Systems Command as the functional manager for the NALCOMIS 
system. OPNAV-Ol provides functional requirements and 
guidance for administrative and personnel sub-system modules. 

Through this diversity of functional managers, the SNAP 
Program Office must try to coordinate efforts in software 
system development without having the authority or power to 
halt duplicate systems development. A primary case in point 
is the development of two intermediate level shipboard 
maintenance management systems cited in Chapter III, the 
Intermediate Maintenance Management System (IMMS) and the 
Maintenance Resource Management System (MRMS). 

The Intermediate Maintenance Management System (IMMS), 
sponsored by the Naval Sea Systems Command code CLD (NAVSEA- 
CLD) , was developed by the Navy Management Systems Support 
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Office (NAVMASSO) to provide shipboard intermediate 
maintenance facilities (AR, AS, and AD) as a production and 
man-hour accounting management package. The Maintenance 
Resource Management System (MRMS), developed under the 
sponsorship of Naval Sea Systems Command (NAVSEA)Code PMS-331, 
with PMS-331 also acting as the Central Design Agency, was 
designed as an intermediate maintenance facility workload 
manager for the shore based Ship Intermediate Maintenance 
Activities (SIMA). 

These competing systems have proponents among the varying 
Fleet Commander and Type Commander staffs. OP-043, as the 
formal functional manager for shipboard maintenance systems, 
has proposed that the MRMS program be adopted as the fleet 
standard intermediate maintenance management program for 
afloat intermediate surface and non-Trident submarine 
activities and Shore Intermediate Maintenance Activities 
(SIMA). 

The naval aviation establishment has developed its own 
intermediate maintenance management program designed to 
operate on the SNAP I Honeywell DPS 6 hardware. The Naval 
Aviation (NALCOMIS) system was developed under Commander Naval 
Air Systems Command (NAVAIRSYSCOM) code PMA-270 sponsorship, 
with the Fleet Material Support Office (FMSO) as the Central 
Design Agency (CDA). This system was designed to meet the 
maintenance management needs for both carrier-based and 
ashore-based Air Intermediate Maintenance Departments (AIMD). 
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Along with the various functional managers described 
above, the SNAP Program Office also must coordinate its 
efforts with the policy guidance and direction provided by 
both the Navy's Information Resource Management Office (OP- 
941) and the Navy's Non-tactical ADP Policy Committee. Figure 
4-2 shows the current program management structure for the 
SNAP program. 

The position of OP-941 as the Requirements Officer for 
the SNAP program places the Navy's Information Resource 
Management (IRM) office in the position of being the resource 
sponsor for the SNAP program. 
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CHAPTER V 


ALTERNATIVE SNAP III DEVELOPMENT PLAN 

This proposal is intended to offer an alternate path of 
development for the "SNAP III" system development. It rests on 
the integration of program development and management 
responsibilities in a single Project Manager devoted to hardware 
and software resystemization of the existing SNAP I and SNAP II 
systems. This proposal also assumes that a single Navy Central 
Design Agency (CDA) will be responsible for design, programming 
development and fielding of the "SNAP III" system. 

The "SNAP III" system should be a maintenance centered 
logistics system incorporating organizational maintenance, 
intermediate maintenance, inventory management, financial 
management and personnel database modules. Administrative 
databases, word processing and accountable functions, (including 
Food Service Management, Retail Operations Management, and 
Disbursing) while being available on smart terminals should not 
be part of the logistics network. 

The next generation of shipboard non-tactical logistics 
computer systems needs to establish the weapons platform's 
configuration as the baseline for development of the new system. 
The Ship Configuration Logistics Support Information System 
(SCLSIS) database developed by NAVSEASYSCOM and the Navy Supply 
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Systems Command provides the tool for interrelated configuration 
management for weapon platforms. Configuration is the key and 
drives the requirements for organizational and intermediate 
maintenance, onboard repair parts and organizational financial 
needs. 

Currently, configuration, the key element of maintaining 
the proper inventory of job skills, technical/maintenance data 
and repair parts, is not being controlled by the personnel 
responsible for the equipment on board the ship - the work 
centers. The NAVSEA established configuration managers perform 
this task for a class of ships. 

Work center personnel are responsible for submission of the 
OPNAV form 4790/CK Configuration Change Report for 
organizational maintenance that changes the ship's 
configuration, and for reviewing the OPNAV form 4790/CK being 
submitted by intermediate and depot activities that change the 
ship's configuration. This requirement for review and 
submission of the OPNAV form 4790/CK does not adequately place 
the burden of responsibility for maintaining current, accurate 
configuration data upon the shoulders of the work center 
assigned to maintain and support the installed equipment. 

The problem with the existing configuration management 
policy is the time delay from equipment installation to receipt 
of a proper COSAL and adequate parts support. Because of the 
time delay imposed by the current configuration review and 
documentation procedures, a time lag of over 24 months from 
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submission of a OPNAV form 4790/CK to receipt of spare parts is 
not uncommon. The time delay from installation of new equipment 
to formal acknowledgement of the configuration change by way of 
the SPCCNOTE 4440.1, is normally six months. Figure 5-1 shows 
the current flow of configuration change reports. 

With such time delays between installation of equipment and 
receipt of proper repair parts support, there is little 
incentive for the work center to take an active interest in 
ensuring that the configuration file is accurately maintained. 

By implementing a few changes to the way, configuration 
data is processed, the time delay of incorporation of a new 
equipment into the ship’s COSAL can be reduced from six months 
to a matter of days. Also, repair parts support can be improved 
by at least six months. Figure 5-2 shows the proposed data flow 
changes. 

By allowing the ship to enter the new equipment into the 
COSAL at the time of installation, the technical documentation 
for repair part support is immediately available to the 
technician. Also, by having the Naval Sea System Centers on the 
Atlantic and Pacific directly order the NAVSEA funded repair 
parts for the ship, after validation of the configuration 
change, will reduce the time lag in receipt of those parts 
onboard. 

Moving from configuration to maintenance, definition of 
installed equipment repair philosophy (piece part repair, remove 
and replace) determines the maintenance requirements in terms of 
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personnel skills test equipment and repair parts carried 
onboard. 

Supply and financial systems, while important to the 
maintenance and operation of a unit, is for a large part a by¬ 
product of maintenance requirements at the organizational level. 
Without an internal maintenance requirement, supply and 
financial support onboard a Navy organization becomes minimal. 

In a descending order of hierarchy, configuration 
management, maintenance and then supply/financial efforts should 
be emphasized in the development of the "SNAP III" system. 

Development of an integrated maintenance module (which 
would provide direct maintenance data input and output between 
the organizational and intermediate level maintenance 
organizations) is the first step in this alternate proposal. 
The capability should exist to allow this maintenance management 
module to function as an organizational level overhaul work-load 
scheduling and management system to replace the current Ship's 
Force Overhaul Management System (SFOMS). 

The maintenance management module must be interactive with 
the user, providing maintenance scheduling and work flow models 
at the minimum. Data collection and analytical tools for repair 
part consumption as provided in the current Maintenance and 
Material Management (3-M) Maintenance Data Collection (MDC) 
system should be available to the organizational level as well 
as transaction reports provided to the Type Commanders and the 
Ship's Parts Control Center (SPCC). 
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The maintenance module must provide organizational level 
forces with the capability to develop and revise weekly, 
monthly, quarterly and semi-annual Planned Maintenance 
schedules. This capability should include Critical Path 
maintenance scheduling that takes personnel skill requirements, 
and the number of personnel and equipment availabily onboard, 
into account. Integration of unplanned maintenance with 
scheduled (PMS) maintenance, and the impact in terms of 
rescheduling or deferral of planned maintenance when superseded 
by unplanned failure maintenance, should be available. 

The maintenance system should be designed to use digitized 
engineering and technical drawings. Efforts should be made to 
incorporate the Engineering Data Management Information and 
Control System (EDMICS) into the maintenance module design from 
the outset. EDMICS data should be provided to ships as it 
becomes available, not held until the EDMICS’ database is 
completed. 

A direct maintenance-supply interface should be provided to 
allow complete on-line and real-time visibility of repair part 
status for maintenance actions. Additional maintenance-supply 
interfaces should include the capability of automated material 
requisitioning five to seven days prior to the performance of 
a Planned Maintenance action scheduled on the weekly PMS 
schedule without manual interface. This capability should 
include the ability to pull the required material for a 
particular maintenance action as a complete job, and package the 
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material for pick-up by the work center the day before the 
maintenance action is scheduled. 

Supply inventory management should take advantage of source 
data entry technology. The Department of Defense LOGMARS 
program provides a vehicle for data capture through bar codes on 
DD form 1348 issue and shipping documents as well as the 
material packaging. Use of bar code equipment to receive, 
store, issue and inventory material is one of the sources of 
productivity and accountability enhancements that must be 
included in any new supply system. 

The new supply system should have the capability to group 
requisitions by storeroom to aid in having material delivered to 
the ship in containers that can be received and moved directly 
to a particular storeroom. An interface should be developed 
between the Uniform Automated Data Processing System 
(UADPS)/Stock Point ADP Replacement Project (SPAR) and the Naval 
Integrated Storage Tracking and Retrieval System (NISTARS) 
automated warehousing system to allow packaging of material in 
containers that are sized to be moved on shipboard cargo 
elevators. Material packaged this way can be moved much more 
quickly into the storerooms, with less chance of pilferage or 
other loss upon receipt onboard ship. 

The packaging of repair parts for direct stowage into 
storerooms would provide increased inventory control and quicker 
on-load, especially for aircraft carriers. Copies of issue 
documents would be provided on magnetic or optical media for 
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input into the computer system. These issue documents would be 
placed in a material-pending receipt file. The actual receipt 
of material, both those moved to storerooms, in containers, and 
large material not transportable by cargo elevator, would take 
place in the storerooms where the material will be stocked. The 
break-out of the cargo elevator-sized packing containers in the 
storerooms would allow orderly receipt of material. The 
material as it is received and stored in the storerooms would be 
recorded by bar code requirement. These receipt files would 
then be electronically matched against the material-pending 
receipt file. Documents in the material pending receipt file 
that are not matched by actual receipt as recorded by material 
storage, or issued in the case of direct turn-over (DTO) 
material, would be sent as exception files to the issuing 
activity. The issuing activity would be responsible for 
processing the material survey documentation via the receiving 
activity as is now the case. 

Maintenance management when broken down into its essential 
elements rests on the allocation of the following resources: l) 
personnel skills (rates/grade and NEC), 2) equipment, 3) 
material/repair parts and 4) time. These basic elements of 
maintenance management and maintenance scheduling remain the 
same throughout organizational, intermediate and depot level 
maintenance. These elements do not vary for aviation, submarine 
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and surface forces. The need for completely separate aviation 
and surface maintenance systems should be seen as redundant. 

One separate logistics system should be singled out to 
remain as a stand-alone system. The Trident Logistics Data 
System (LDS), developed to support a single weapon system, is 
implemented at the Trident Refit Bases Bangor, Washington, and 
Kings Bay, Georgia. These facilities were designed to provide 
total patrol-refit support for the Trident weapon system. The 
Trident LDS provides a model for logistics integration. 
Designed to provide patrol-refit cycle maintenance support, the 
Trident LDS provides the integration of organizational level 
maintenance and supply support during patrol cycles and referral 
of maintenance and supply support beyond organizational 
(skill/material) or patrol (time) capabilities to the servicing 
Trident Refit Base. 
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Chapter VI 

PROPOSED INFORMATION RESOURCE MANAGEMENT (IRM) AND LOGISTICS 

ORGANIZATIONS 

This chapter will address the need for an organizational 
revision of the Navy's Information Resource Manager and 
Logistics management structures. 

♦WHY IS THE CURRENT ORGANIZATIONAL PLACEMENT OF THE NAVY'S 
INFORMATION RESOURCE MANAGER (IRM) UNSATISFACTORY? 

The current structure of the Navy's Information Resource 
Management program places a Flag Officer junior (Rear Admiral, 
Lover Half) to the Type Commanders (Vice Admiral) and 
Headquarter System Command (Rear Admiral, Upper Half) as the 
Navy's senior Information Policy director. 

Even though the current structure gives the Information 
Resource Manager the positional authority to set Navy policy and 
direction for Information Systems, he is disadvantaged 
positionally, as well as by rank. Being two levels down in the 
OP-09 organization (OP-941), he does not have direct access to 
the Chief of Naval Operations or the Deputy Chiefs of Naval 
Operation platform sponsors (OP-02, OP-03, OP-05). 

♦WHAT IS THE RELATIONSHIP BETWEEN IRM/IS AND LOGISTICS? 

What is Information? Information is a resource that has a 
value to the user. Management of information is a new principle 
that must be understood in the Navy. Data contained in Navy 
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databases has an intrinsic value and a cost of storage. The 
management of this resource when viewed from this perspective is 
not so different as the management of physical material, i.e. 
supply parts. Information, or more precisely the management of 
information, in this context becomes a logistical resource. 

The management of information is a logistics resource. 
This concept can be clearly seen in the Integrated Logistics 
System (ILS) as applied to acquisition of Major Weapons Systems. 
The development of the Computer Aided Logistics System (CALS) to 
aid in the design and development of Major Weapons Systems makes 
use of information as a logistics resource. 

CALS and ILS are used primarily for support of tactical 
weapons systems. These major weapons systems developed under 
the guidance of the Warfare sponsors (OP-02, OP-03, OP-05), also 
contain non-tactical logistics systems requirements. 

♦WHERE SHOULD THE NAVY'S INFORMATION RESOURCE MANAGER BE 
PLACED? 

Viewing information as a logistics resource, it makes sense 
that Information Resource Management should be moved to the 
Deputy Chief of Naval Operations for Logistics, 0p-04. OP-04 
himself, should be designated as the Navy's Information Resource 
Manager. This move of functional responsibility from OP-09 to 
0P-04 repositions the Navy's IRM function from a third level 
office with a one star admiral in OPNAV, to a three star flag 
officer Deputy Chief of Naval Operations. 
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The movement of Information Resource Management to OP-04 
aligns the functional responsibility of Information Systems 
management with that of logistics policy and management in the 
Navy. The Naval Data Automation Command (NAVDAC) and Navy 
Regional Data Automation Centers (NARDAC) should also be moved 
under OP-04. 

*HOW SHOULD NON-TACTICAL INFORMATION SYSTEMS BE DEVELOPED? 

Non-tactical information systems for logistics, 
administration, personnel and training should be developed under 
a single program office. Many databases that require logistics 
data also need personnel data. Likewise, training databases 
need personnel and logistics data. Establishing a single 
program office to develop these non-tactical information systems 
would reduce system development and lead to system 
standardization in the Navy. 

♦WHO SHOULD DETERMINE THE FUNCTIONAL REQUIREMENTS FOR NON- 
TACTICAL INFORMATION SYSTEMS? 

Program Sponsors for major systems should have input for 
functional requirements to support their projects. Design and 
development of a non-tactical information system should rest, 
however, with a single Central Design Agency (CDA). 

Having only one command develop all non-tactical 
information systems helps eliminate duplication of logistics and 
administrative systems. Elimination of duplicate information 
system development efforts and standardization of non-tactical 
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information systems will save information system resource 
dollars. 

♦WHO SHOULD BE THE CENTRAL DESIGN AGENCY FOR NON-TACTICAL 
INFORMATION SYSTEMS DEVELOPMENT? 

The Navy Management Support Systems Office (NAVMASSO) 
should be designated as the single non-tactical information 
systems Central Design Agency. 

♦WHERE SHOULD THE NON-TACTICAL INFORMATION SYSTEMS CENTRAL 
DESIGN AGENCY BE PLACED ORGANIZATIONALLY? 

The Navy Management Support Systems Office (NAVMASSO) 
should be placed under the direction of the Naval Supply Systems 
Command (NAVSUP). NAVMASSO was created from the Fleet 
Assistance Group, Atlantic, a department of the Fleet Material 
Support Office (FMSO). 
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CHAPTER VII 


CONCLUSIONS AND RECOMMENDATIONS 

Information is as much a resource as men and material. 
Various elements of the Navy are just now realizing this fact. 
The de-centralized management system in place in the Navy, which 
gives Fleet Commanders and Type Commanders considerable latitude 
over management issues and resources, serves with merit as 
attested by the Navy's ability to accomplish the operational 
missions in the Mediterranean and Middle East in the mid to late 
1980s with resources at hand. While this system works 
remarkably well for operational initiatives, the Navy must 
recognize the funding and Information System (IS) duplication 
that such a system creates. 

The Defense Management Report issued by Secretary of 
Defense Cheney in June 1989 specifically targets logistics as an 
area to be cut. Shipboard Non-tactical Automated Data 
Processing systems fall in the area of logistics as defined by 
DOD, Army and Air Force. To avoid major program cuts and loss 
of control over logistic systems, the Navy needs to reorganize 
its Logistics and Information Resource Management policies and 
organization. 

The solution to the Navy's Information Resource Management 
problems of duplication and lack of communication among 
organizations is not new. Rear Admiral G.E. Moore, II, SC, USN 
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then vice Commander of the Naval Supply Systems Command, in 
1969, gave an address at the Institute of Management Sciences in 
April 1969. The following quotes are taken from the June 1969, 
Supply Corps Newsletter, giving the text of RADM Moore's 
address. 


A major constraint impinging on effective system 
design is a general lack of awareness of the range and 
depth of current off-the-shelf capabilities. This 
problem is accentuated by a shortage of imagination 
and innovative thinking on the part of system 
designers and top level management. We design, 
redesign, and over design from the minuscule and 
extrapolate out to the total system. The result is a 
hodgepodge network of subsystems tied together in a 
rather inefficient fashion. This overemphasis on 
segments of the problem tends to obscure the original 
purpose of the system, and invariably results in the 
organization having to be fitted to the system, rather 
than the system fitting the organization's problem. 

Our technological forecast in information¬ 
processing provides one overriding conclusion: 

Quantum improvements in information-processing 
technology are no longer likely to be made through the 
brute force approaches we have been taking in the 
past, particularly as manifested by faster computer 
cycle times and more sophisticated program language 
repertoires. Yet, large-scale improvements are 
possible if we can take advantage of current and 
improving technology and add the missing ingredient- 
total communication, that is - man to man, man to 
machine, or machine to machine. 

To achieve total communications, at least four 
areas must be stressed: 

First, to exploit technology and properly utilize 
technological potential, user requirements must be 
satisfied in terms of functions performed, not 
procedures used to perform them. This could cause 
major disruptive changes and casualties among current 
management practices and forms of human organization, 
yet offers potentially great payoffs. 

Second, standardization of procedures, equipment, 
software and data elements-(oriented to function). 
The lack of such standardization is the major source 
of current data handling problems. Unfortunately such 
a program would create numerous casualties among 
vendors, programs and current policies; but this is a 
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price ve will have to pay or suffer an escalation of 
today's confusion. 

Third, make the gear an extension of the man. 

For years lip service has been paid to this concept, 
while a diametrically opposed policy has been pursued. 

Today ve communicate with the machine in a manner more 
amenable to the machine than the man. If this 
extension concept is to be implemented, the machine 
must be prepared to converse with man through his 
natural senses (such as sight and hearing) in his 
operating mode, that is, an interactive question and 
answer experience. 

Fourth, and finally, adopt new ways of organizing 
the machine and systems of machines. 1 

RADM Moore's remarks of 30 years ago still have validity in 
today's information system environment. The need for 
standardization among the various existing non-tactical 
information systems is more important today than at the time he 
made his remarks. The proliferation of micro-computers in the 
Navy makes most any command a potential software developer. 
This explosion of computers and in particular, local command 
developed software, lacks visibility and control. 

Local development of software is not itself a bad thing. 
However, most locally developed software systems lack adequate 
documentation. Once the original program developer is 

transferred, this software can become a ticking time bomb, ready 
to obliterate data that a command has come to rely on. 

The recommendations that follow are designed to allow the 
Navy to gain control of non-tactical systems development. 

A. Review, consolidate and reissue all SECNAVINST and 
OPNAVINST pertaining to Information Resource management. The 
current base instruction for the Navy's Information Resource 
Policy SECNAVINST 5230.10 was last issued in 1987. The Navy 
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instruction setting Information System Life Cycle Management 
(LCM) was issued in 1985. Many changes in legislation and 
technology have taken place since these instructions were 
issued. The policy and procedural instructions for Information 
Resource Management (IRM) should be reviewed annually and 
updated as required. 

The SECNAVINST and OPNAVINST on Information Resource 
Management and administration should be the standard that 
applies throughout the entire Navy. These instructions should 
prohibit the development of Information Systems by Hardware 
System Commands, Fleet Commanders, Type Commanders, Squadrons 
and individual units without prior approval by the Navy's IRM. 

B. The Navy needs to establish a single database of non- 
tactical systems developed to date. A one time reporting 
directive should be issued by the Chief of Naval Operations that 
requires all Navy commands to report to Commander Naval Data 
Command (NAVDAC) any information system(s) they have developed 
internally or have had developed by a contractor. The directive 
should require that the commands send a copy of the application 
program to NAVDAC. Additionally, the commands need to report 
the system name, puzpose of the system, development date and who 
developed the system. Further, the programming language and the 
Navy's rights/ownership of the system should be stated. If 
available, program source code and documentation should be 
provided to NAVDAC. 
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The information gained from this one-time. Navy wide survey 
will provide a baseline of existing non-tactical information 
systems in the Navy. 

Organizational realignments as proposed in chapter six 
should be given serious consideration. Moving the Information 
Resource Management responsibilities from OP-09 to OP-04 
presents an opportunity to consolidate logistic and information 
systems. 

SNAP III development should involve all functional 
managers. A piece-meal approach in developing software 
application programs for SNAP III will lead to the same system 
fragmentation that existed in the SUADPS/SNAP I environment. 
The system development approach should provide a maintenance 
based configuration management that provides integrated 
maintenance and supply support. 

The approach of the Naval Supply Systems Command, in taking 
a total review of supply procedures and manning requirements for 
incorporation in SUADPS resystemization, defines the approach 
all functional managers should take in development of SNAP III. 
Maintenance system development should look at incorporating 
emergent technology and personnel trends. A total review of 
maintenance philosophy and requirements, such as done for Supply 
System requirements in the Supply Corps 2010 study, should be 
performed for shipboard and ashore maintenance functions. 

As a follow-on to this project, a review of existing Air Force 
and Army unit and intermediate level maintenance and support 
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automated systems should be performed. This review should be 
designed to determine if these services have existing systems 
that could be used by the Navy for organizational and 
intermediate maintenance and supply support. This follow-on 
study could be used by the Navy to validate the requirement to 
proceed with an independently developed SNAP III logistics 
system. 

As stated in Chapter V, maintenance management rests on the 
allocation of four essential elements: personnel skills, 
equipment, material/repair parts, and time. A first step in 
reducing system duplication is to recognize that these elements 
remain constant at the organizational, intermediate and depot 
levels of maintenance. Only the depth or range of the elements 
change at the varying levels. Consolidation of maintenance 
management systems helps to reduce support system costs. 
Recognition that system standardization is needed in maintenance 
systems is seen in the 20 February ALNAV message form OP-94, 
that makes the Maintenance Resource Management System (MRMS) the 
standard maintenance management system for afloat and ashore 
ship intermediate maintenance activities. 

with shrinking Defense budgets and the push by the 
Secretary of Defense to reduce and consolidate logistic support 
requirements, the need for the Navy to standardize and 
consolidate logistic systems grows. If the recommendations 
contained in this report are implemented, the first steps to 
reducing redundant development of non-tactical systems will have 
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been accomplished. Additionally, the organizational 
realignments contained in this paper will strengthen both the 
Navy's Information Resource Management and Logistics 
organizations. 
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1. G.E. Moore, II, "Projected Logistics Information 
Systems," Remarks given to the Institute of Management 
Sciences in Washington, D.C. 18 April 1969 as published in 
Navv Supply Corps Newsletter . June 1969, pp. 10-11. 
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